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Abstract: We present our ongoing work on requirements specification and analysis for the geographically distributed 

software and systems. Developing software and systems within/for different countries or states or even 
within/for different organisations means that the requirements to them can differ in each particular case. These 
aspects naturally impact on the software architecture and on the development process as a whole. The chal¬ 
lenge is to deal with this diversity in a systematic way, avoiding contradictions and non-compliance. In this 
paper, we present a formal framework for the analysis of the requirements diversity, which comes from the 
differences in the regulations, laws and cultural aspects for different countries or organisations. The frame¬ 
work also provides the corresponding architectural view and the methods for requirements structuring and 
optimisation. 


1 INTRODUCTION 


Globalisation of the software and systems devel¬ 
opment offer great opportunities for the development 
industry. However, they also mean new challenges 
coming from the diversity of requirements on dif¬ 
ferent locations, especially in the sense of legal re¬ 
quirements and regulatory compliance. The reasons 
for the differences in software and systems require¬ 
ments within different countries, states and organisa¬ 
tions are the cultural and economics diversity, as well 
as the diversity in standards, legal regulations and 
laws. These challenges have some similarities with 
the problems of product customisation and the devel¬ 
opment of product lines, but the core of the architec¬ 
ture requirements is different due the specific nature 
of the relations between the requirements for the geo¬ 
graphically and organisationally distributed develop¬ 
ment and application of software. 

Requirements engineering (RE), i.e., require¬ 
ments elicitation, evaluation, specification, and de¬ 
sign producing the functional and non-functional re¬ 
quirements, is one of the key disciplines in the soft¬ 
ware development domain. It has a critical impact on 
the product’s quality. Requirements-related errors are 
often a major cause of the delays in the product de¬ 


livery and development costs overruns, cf. e.g., (van 

Lamsweerde 

|2008l|Pretschner et al.l|2007l|Rinke and 

Weyer 

2007 

1 . There are several methodologies on 


development of software systems from requirements. 


also enclosing CASE tools support, e.g., ( 

Broy and| 

Slotosch 

2001 I 

lolzl et al. 2010| Spichkova 

2011 

Spichkova et al. 

2012|l. The RE task is 

challeng- 


ing even in the case of a local (non-distributed) de¬ 
velopment of a product for application within/for a 
single country or organisation, i.e. where the sys¬ 
tem acts within an environment with a uniform set 
of standards, legal regulations, etc. Thus, in the case 
of global development we need to have an approach 
that deals the corresponding issues in a systematic 
and scalable way. There are several approaches that 


check requirements for compliance (Breaux 

et al.l 

120081 IMaxwell and Antoni |2009l|Siena et al. 

lbb9hl 


or ensuring the compliance of the outcomes of busi¬ 
ness processes against outcome-focused regulations 


( |Yin et al^|2013| l. We are going a step further, aiming 
to cover the RE aspects for the geographically dis¬ 
tributed development and application. To minimise 
the overall effort while specifying and also ensuring 
required software and system requirements in a global 
development context, we elaborated a logical frame¬ 
work. The framework provides methodological struc¬ 
turing the requirements for the geographically dis¬ 
tributed product development and application, as well 
as developing of the corresponding global architec¬ 
ture requirements. The purposed approach will help 
to analyse the relations between requirements and to 
trace requirements’ changes in a global context. 
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Outline: The rest of the paper is structured as 
follows; Section |2] overviews related work on inte¬ 
gration architecture and RE as well as on regulatory 
compliance within the field of software engineering. 
In Section]^ we present our view on the architectural 
dependencies for the requirements for a global de¬ 
velopment and geographically distributed product ap¬ 
plication. In Section]^ we introduce the core ideas 
of requirements structuring process and requirements 
analysis in a global context. Section [^concludes the 
paper by highlighting the main contributions of the 
paper and describing the future work directions. 


2 RELATED WORK 


Glinz (2007 1 surveyed the existing definitions of 
non-functional requirements (NFR), highlights and 
discusses the problems with the current definitions, 
and contributes concepts for overcoming these prob¬ 
lems. In our work, we are mainly focusing on NFR in 
the sense of legal aspects and regulatory compliance, 
also taking into account human factor aspects of the 
requirement modelling (|SpichkoTO 2012|l. 


Integrating Architecture and Requirements En¬ 
gineering: The main purpose of the requirements 
specification (RS) is to elicit and to document the 
given problem (product/software/system) using con¬ 
cepts from the problem domain, i.e. on the RE phase 
we are speaking only on the problem statement. In 
contrast to this, the aim of a software architecture 
(SA) is to design a draft of the solution for the prob¬ 
lem described in the RS, at a high level of abstrac¬ 
tion. Thus, there are tight interdependencies between 
functional/non-functional requirements and architec¬ 
tural elements, which makes the integration of the RE 
and architecture crucial (|In et al.| |2001t |Egyed et al.| 


20011. The results of the empirical study conducted 


by Ferrari and Madhavji ( |2007p also have shown that 
the software architects with the knowledge and expe¬ 
rience on RE perform better, in terms of architectural 
quality, than those without these knowledge end ex¬ 
perience. 

Nuseibeh (2001|l described a spiral model-like de¬ 


velopment cycle of requirements and architecture. 
|Pohl and Sikora| ( |2007| l went further and have pro¬ 
vided methodical guidance for the co-design. An 
experience-based approach for integration architec¬ 
ture and RE is presented by [Paech et al. 


This approach that supports the elicitation, specifica¬ 
tion and design activity by providing experience in 
terms of questionnaires, checklists, architectural pat¬ 
terns and rationale that have been collected in earlier 


successful projects and that are presented to develop¬ 
ers to support them in their task. 


The REMseS approach (Braun et al. 20141 aims 
at supporting RE processes for software-intensive em¬ 
bedded systems. The authors introduced fundamen¬ 
tal principles of the approach and gave a structural 
overview over the guide and the tool support. 

In contrast to these approaches, our research cov¬ 
ers the regulatory compliance aspects and is oriented 
on legal requirements representation and analysis in 
the scope of the global software development. 


Regulatory compliance: A survey of efforts to sup¬ 
port the analysis of legal texts in the context of soft¬ 


ware engineering is presented in (Otto and Anton 


2007| l. The authors discuss the role of law in require 
ments and identify several key elements for any sys 
tern to support the analysis of regulatory texts for re¬ 
quirements specification, system design, and compli¬ 
ance monitoring. [Nekvi et~ar p011| l also identified 
key artefacts, relationships and challenges in the com¬ 
pliance demonstration of the systems requirements 
against engineering standards and government regu¬ 
lations, also providing This work provides a basis for 
developing compliance meta-model. 

Kiyavitskaya et al. (2008|l investigated the prob¬ 


lem of designing regulation-compliant systems and, 
in particular, the challenges in eliciting and manag¬ 
ing legal requirements. Breaux et al. ( |2006 1 reported 
on an industry case study in which product require¬ 
ments were specified to comply with the U.S. federal 
laws. [Maxwell and Antm (20091 performed a case 
study using our approach to evaluate the iTrust Medi¬ 
cal Records System requirements for compliance with 
the U.S. Health Insurance Portability and Account¬ 


ability Act. Siena et al. (2009a i presented the guiding 
rules and a framework for for deriving compliant-by- 
construction requirements, also focusing on the U.S. 
federal laws. 

In contrast to these approaches, our research is ori¬ 
ented on global software development, dealing with 
diversity in standards, legal regulations, etc. within 
different countries and organisations. 


3 GEOGRAPHICALLY 
DISTRIBUTED 
ARCHITECTURE 

Suppose that we have to develop M products (soft¬ 
ware components/systems) T’l) • • •) Pm ■ We denote the 
set of products by P. Each product Pj, 1 < i <M has 
the corresponding set of requirements Rp.. However, 
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in the case the legal requirements and the regulatory 
compliance are taken into account, the set of require¬ 
ments will depend on the regulations and laws of the 
country/state the product is developed for. 

In the case of global and remote develop¬ 
ment (Spichkova et al. 20131, we have to deal with 
cultural and economics diversity, which also has an 
influence on the software and system requirements. 
Suppose the products Pi,...,P m are developed for 
application in N countries Ci,...,Cn with the corre¬ 
sponding 


• regulations/laws RegulCi,... ,RegulCN and 

• cultural/economics, i.e., human factor ( jBorcher^ 
|2003| l, influences HFC\,... ,HFCn. 


We denote the set of requirements to the product P, 
valid for the country Cj by Rp^. The complete set of 
requirements to the product P, is then defined by 

R^‘ = [jRp; (1) 

7=1 

The sets of requirements Rp. might be different for 
each product P, in different countries, i.e. Pp' is not 

necessary equal to Rp for the case jl ^ j2. 

Figure presents the corresponding architectural 
dependencies for the requirements based on the regu¬ 
lations and laws of the country Cj. We divide the set 
of requirements Rp, in two (disjoint) subsets. For each 
of these subsets, we have to distinguish two separate 
parts: general and country-specific: 

. 

• RLp denotes the requirements based or depend¬ 
ing on the regulations and laws, which could 
be country/state/organisation-specific. Require¬ 
ments of this kind does not depend on the human 
factor related aspects. 

C- C C- 

RLp. = RLgeneralp. U RLspecifiCp. (2) 

RLgeneralpI = ■ ■ ■ = RLgeneralp^ (3) 

• RFNp^ denotes the functional and non-functional 
requirements that are independent from the regu¬ 
lations and laws, but may depend on the human 
factor related aspects, which could be country- 
specific. 

RFNpj = RFNgenerafp^ \J RFNspecific^p. (4) 

RFNgeneralp^ = ■ ■ ■ = RFN generalp^ (5) 

For simplicity, we denote the general subsets by 
RLgeneralp, and RFNgeneralp, respectively. 



Figure 1: Architectural dependencies for the requirements 
based on the regulations and laws of the country Cj 


Given the set RL^pp be the set of all legal require- 
ments of the country Cj, we can see the set RLp' as a 
projection of RL^pp to the product P,: 

KI=RI^1l\p, ( 6 ) 

On this basis, we can say that the set of legal re¬ 
quirements for the country Cj related to the develop¬ 
ment of products Pi,... ,Pm is defined as a union over 
the corresponding requirements sets: 

M 

RL^^i = IJPL^ (7) 

i=l 

Flowever, it is not efficient to base the requirements 
analysis for the geographically distributed develop¬ 
ment on the sets RL'^i: 

• The sets RegulCi,... ,RegulCN could have a joint 
subset Regul of the regulations/laws that are equal 
for all countries Ci,...,Cn: 

Regul — RegulCi n • • • n RegulCj^ (8) 

We denote for each RegulCj the corresponding 
compliment to Regul (i.e. the country-specific 
subset) by RegulCi = RegulCi \ Regul. 

It it is important to identify these subsets as well 
as the corresponding subsets of RLp',... ,RLF^ , as 
this helps to trace the PL-requirements’ changes 
more efficiently. 
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• Some requirements in RL^i can be stronger ver¬ 
sions of another requirements from this set. For 
example, if reqi € RLf-'^ and req2 G RL^‘^ are not 
equal, they both will belong to RLf't, even if reqi 
is a refinement of req 2 - In this case, we call 
req2 a weaker version of req\ and denote it by 
reqi req2- 

Thus we need to have a structured architecture for the 
legal requirements on the products Pi,...,P m- For 

c' ffiin 

this reason we build the corresponding sets RLrJ 
and RLf^i , where RL^t denotes the strongest set of 
legal requirements for the country Cj (related to the 
concrete products development), and RLPJ.'” denotes 
the set of legal requirements that should be fulfilled 
by all the products Pi,... ,Pm developed in the coun¬ 
try Cy. 

RL^i’”‘" = RL^p[ n • • • n RL^pI (9) 

RLpi* is an optimisation of Rlfi, where all the weaker 
versions of the requirements are removed using the 
algorithm presented in Section]^ 


4 REQUIREMENTS 
STRUCTURING AND 
ANALYSIS 


In our framework, we perform the analysis based 
on the optimised views on the requirements sets, 
focusing on the regulatory/legal aspects. First of 
all, we analyse the sets of relevant regulations 
RegulCi,... ,RegulCj\i. Three cases are possible: 

• In the case Regul — 0, we have the situation when 
the regulations are completely different for all 
Cl,. ..,Cn. This also implies that RLgeneralp- — 0 
for all Pi, I <i < M, i.e., RL^j = RLspecific^p.. 

We have to trace all the sets RLspecifiCp, sepa¬ 
rately: changes in RegulCj do not influence on the 
global development process. 


• The regulations are not completely identical for 
Cl,..., Cn, but Regul ^ 0. If we can rely 
on the statical nature of this requirements (i.e. 
that these requirements do not change over the 
time of the development and the application), 
it would be beneficial to apply the component- 
based development paradigm ( |Crnkovic et al. 
2007|l: the requirements RLgeneralp. or at 


least the major part of them should corre¬ 
spond to architectural components(s) that are 
separate from the components corresponding to 
RLspecific^',... ,RLspecific'^^ . However, if any 


of regulations sets RegulCj has some changes, this 
would influence on the development process as a 
whole. 

• In the case Regul = RegulCi = ■■■ = RegulCj, 
we have the situation when the regulations are 
completely identical for all Ci,..., C^, which also 
means RLp = RLgeneralp^ If we can rely on 
the statical nature of this requirements, we have 
the simplest case for the development process: 
we develop a single component (system) from 
RLgeneralp. to apply if for all Ci,..., O/. 

Thus, RLpi'^'^' is defined on basis of Regul. The 
corresponding product-centred view on the architec¬ 
tural dependencies is presented on Figure The al¬ 
gorithm of constructing trivial: we check all 

C C- 

the requirements in Rp'^ ,... ,Rp^ to And out those ele¬ 
ments, which belong to each of the sets. 



Figure 2: Architectural dependencies for requirements 
specified for the product /)■ 


Our approach is based on the ideas of refinement- 
based specification and verification. On the formal 
level, we need to define which exactly kind of a refine¬ 
ment we mean, e.g., behavioural, interface or condi¬ 
tional refinement ([Spichkow 2008[ Broy and Stplen 


2001|l. However, on the level of the logical architec 


ture and modelling of the dependencies between the 
(sets of) requirements, we can abstract from these de¬ 
tails. 

In this paper, we present a simplified version of 
the optimisation algorithm. It can be applied to build 
the set RLpi* on the basis of RL^i (cf. Figure 
for the country-centred view), to build the set Rp* 
(cf. Figure for product-centred view) as well as to 
build the strongest global set of requirements R* over 
Cl,...,C at (cf. Figure]^. We start the algorithm with 
an empty set and build it up iteratively from the ele¬ 
ments of the corresponding set. 
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Figure 3: Requirements structuring for the distributed de¬ 
velopment of products Pi,.P m 


Step 0: RL^J* = 0, X = RL‘^j. 

Step 7: If X 7 ^ 0, the RL^i* is complete, otherwise 
choose a requirement req G X: 

• If a copy of req already belongs to RLpi* or r is 
a weaker version of any requirement from RLpi , 
the set should not be updated on this iteration: 
{req G RLpi* V 3y G RLpi* : req -w y) ^ 

RL^i is unchanged 

• If r is a stronger version of any requirement(s) 
from RL^J , we add r to RL^j and remove all the 
weaker requirements: 

3yi ,...,yK G RLf'j : y\-^req A • • • A yK-^req) ^ 
RL^i* = {RL^i * U req) \ {yi,... ,yA;} 

• If r does not belong to RLpi* and is neither 
weaker nor stronger version of any requirement 
from RL'^i , we add it to RL'^i and proceed the 
procedure with the next requirement from RLpi : 
{req ^ RL^i* A 

^y G RLpi : {req -w y V y -w req) => 

RLpj* = {RLpi* U req) 

Step 2: The req element is deleted from the set X: 

X =X\ req. 

Steps 1 and 2 are then repeated until 7f = 0. 

While identifying 7?L'"'" we will analyse which 
products’ subcomponents can be build once and then 
reused for the whole product set Pi,...,P m. On 


this basis, we will have more efficient process for 
the global software and systems development, also 
having an efficient tracing of requirements changes 
that might come from the changes in the regula¬ 
tions and laws for countries Ci,...,Cn. For example, 
changes in RegulCi imply changes in RLspecifici 
only, which means that only the country-specific part 
of the architectural components for Ci is affected, 
where any changes in Regul might influence the 
global architecture. 

While identifying RL* we will obtain the global 
view on the the products’ requirements, which is not 
overloaded with the variants of the similar require¬ 
ments, where some requirements are just weaker ver¬ 
sions of other. 


5 CONCLUSIONS 

This paper introduces our ongoing work on require¬ 
ments specification and analysis for the geographi¬ 
cally distributed software and systems. Developing 
software and systems within/for different countries or 
states or even within/for different organisations means 
that the requirements to them can differ in each partic¬ 
ular case, which naturally impacts on the software ar¬ 
chitecture and on the development process as a whole. 
Dealing with this diversity and avoiding contradic¬ 
tions and non-compliance, is a very challenging and 
complicated task. A systematic approach is required. 
For this reason, we created a formal framework for 
the analysis of the software requirements diversity, 
which comes from the differences in the regulations 
for different countries or organisations. In this paper, 
we {i) presented our architectural dependency model 
for the requirements on the distributed development 
and application, {ii) introduced the core ideas of the 
corresponding requirements stracturing process and 
requirements analysis in a global context. {Hi) dis¬ 
cussed the the research and industrial challenges in 
this field, as well as discussed our solutions and how 
they are related to the existing approaches. 

Future Work: In our future work we will investi¬ 
gate how to extend the presented ideas to the software 
and systems development that involves hierarchical 
dependencies between the sets of regulations/laws. 
This could be the case if see the set Ci,...,Cn not 
only as the set of countries/states, but also as a set 
of organisations having different internal regulations. 
Then we have to deal with hierarchical dependencies 
with many levels, e.g., (1) organisational regulations, 
(2) state’s regulations and laws, (3) country’s regula¬ 
tions and laws, where we also need to check which of 
the regulations are applicable in each particular case. 
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